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AD HOC SELECTION OF VOICE OVER 
INTERNET STREAMS 

CROSS-REFERENCE TO RELATED 

APPLICATIONS 5 

This application is a divisional application of application 
Ser. No. 10/283,354, filed Oct. 24, 2002, now U.S. Pat. No. 
7,415,005, which claims the benefit of U.S. Provisional 
Application No. 60/350,906, filed Oct. 29, 2001. 10 

STATEMENT REGARDING FEDERALLY 
SPONSORED RESEARCH AND DEVELOPMENT 

The invention described herein was made in the perfor- 15 
mance of work under a NASA contract and is subject to 
Public Law 96-517 (35 U.S.C. § 200 et seq.). The contractor 
has not elected to retain title to the invention. 

BACKGROUND OF INVENTION 20 

Transmission and reception of audio is a mainstay of 
human communication. For example, telephone, CB radio, 
FM/AM radio, and voice mail are typical implementations 
that provide auditory communication. While the telephone 25 
and the CB radio enable bi-directional communication, 
FM/AM radio and voice mail typically provide unidirectional 
communication. Unidirectional communication provides a 
means to convey instructions, information, alerts, and/or situ- 
ational awareness from an audio source to a listener. 30 

Situational awareness may provide an understanding of 
current or past events that may require present or future 
actions. For example, monitoring air traffic control, stock 
exchange broker conferences, mission control communica- 
tions, or police, fire, and EMS dispatch voice communica- 35 
tions provide an awareness. Typical situational awareness 
communications may convey routine activity or situations. 
However, by maintaining an awareness, unusual or critical 
situations may become apparent, and more information about 
the events that lead to the situation may be known by a listener 40 
much earlier. 

Systems that provide situational awareness are typically 
dedicated networks. In other words, dedicated networks are 
constructed for the sole purpose of conveying a particular 
type of information. For example, police, fire, and EMS dis- 45 
patch voice communications may have dedicated network(s) 
to route incoming information to an appropriate agency in a 
timely fashion. Air traffic control and stock exchange broker 
conferences may restrict the number of listeners due to con- 
cerns about security, privacy, subscription fees, and/or cost. 50 

Adding listeners to a communication system may be desir- 
able; however, the addition of listeners may involve extending 
the dedicated network(s). The ability to extend the dedicated 
network(s) may be limited due to a distance between an audio 
source and a listener, security/privacy concerns, and/or cost. 55 

SUMMARY OF INVENTION 

According to one aspect of the present invention, a com- 
munication system comprising a server arranged to actively 60 
propagate at least two audio streams where each of the at least 
two audio streams is a packetized version of an audio source; 
a client operatively connected to the server with a data con- 
nection where a transport protocol actively propagates the at 
least two audio streams from the server to the client; and 65 
software instructions executable on the client for indicating a 
presence of the at least two audio streams; selecting at least 
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one of the at least two audio streams dependent on a listener; 
and directing the selected at least one of the at least two audio 
streams for audio playback. 

According to one aspect of the present invention, a com- 
puter-readable medium having recorded thereon instructions 
executable by a processor, the instructions comprising 
instructions for indicating a presence of at least two audio 
streams actively propagated from a server; instructions for ad 
hoc selecting of at least one of the at least two audio streams 
dependent on a listener; and instructions for directing the 
selected at least one of the at least two audio streams for audio 
playback. 

According to one aspect of the present invention, a com- 
puter system for communications comprising a processor; a 
memory; and software instructions stored in the memory 
adapted to cause the computer system to indicate a presence 
of at least two audio streams actively propagated to a client; 
select at least one of the at least two audio streams dependent 
on a listener; and direct the selected at least one of the at least 
two audio streams for audio playback. 

According to one aspect of the present invention, a method 
for performing ad hoc selection of at least two audio streams 
comprising packetizing the at least two audio streams; 
actively propagating the at least two audio streams from a 
server to a client; indicating a presence of the at least two 
audio streams is performed by the client; selecting at least one 
of the at least two audio streams is perfonned by the client 
dependent on a listener; and directing the selected at least one 
of the at least two audio streams for audio playback. 

According to one aspect of the present invention, a com- 
munication system comprising means for packetizing at least 
two audio streams; means for actively propagating the at least 
two audio streams from a server to a client; means for indi- 
cating a presence of the at least two audio streams at the client; 
means for selecting at least one of the at least two audio 
streams at the client; and means for directing the selected at 
least one of the at least two audio streams for audio playback. 

Other aspects and advantages of the invention will be 
apparent from the following description and the appended 
claims. 

BRIEF DESCRIPTION OF DRAWINGS 

FIG. 1 illustrates a typical computer. 

FIG. 2 shows a block diagram of a communication system 
in accordance with an embodiment of the present invention. 

FIG. 3 shows a block diagram of a communication system 
in accordance with an embodiment of the present invention. 

FIG. 4 shows a flow diagram of software instructions 
executable on an encrypter in accordance with an embodi- 
ment of the present invention. 

FIG. 5 shows a flow diagram of software instructions 
executable on a client in accordance with an embodiment of 
the present invention. 

FIG. 6 shows an exemplary client controls window in 
accordance with an embodiment of the present invention. 

FIG. 7 shows a glossary for icons for an exemplary client 
controls window in accordance with an embodiment of the 
present invention. 

DETAILED DESCRIPTION 

In the following detailed description of the invention, 
numerous specific details are set forth in order to provide a 
more thorough understanding of the invention. However, it 
will be apparent to one of ordinary skill in the art that the 
invention may be practiced without these specific details. In 
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other instances, well-known features have not been described 
in detail to avoid obscuring the invention. 

Embodiments of the present invention relate to an active 
propagation of at least two audio streams from a server to a 
client and selecting at least one of the at least two audio 5 
streams using the client to be directed for audio playback. For 
the purposes of this disclosure, actively propagating the at 
least two audio streams from the server to the client refers to 
the client continuously receiving the at least two audio 
streams. In one or more embodiments, a listener may ad hoc to 
select the at least one of the at least two audio streams to be 
directed for audio playback. For the purposes of this disclo- 
sure, ad hoc selection refers to the listener having the ability 
to select any, all, or none of the at least two audio streams 
continuously received at the client to be directed for audio 15 
playback. 

The invention may be implemented on virtually any type of 
computer regardless of the platfomi being used. For example, 
as shown in FIG. 1, a typical computer (24) includes a pro- 
cessor (26), memory (28), a storage device (30), and numer- 20 
ous other elements and functionalities typical of today’ s com- 
puters (not shown). The computer (24) may also include input 
means, such as a keyboard (32) and a mouse (34), and output 
means, such as a monitor (36). Those skilled in the art will 
appreciate that these input and output means may take other 25 
forms in an accessible environment. The computer (24) may 
be connected to a network (37) or other resources (not 
shown). 

FIG. 2 shows a block diagram of an exemplary communi- 
cation system (100) in accordance with an embodiment of the 30 
present invention. A plurality of audio sources are available at 
an audio source (102). An audio source may include audio 
signals and/or voice signals. For purposes of this disclosure, 
voice signals include those sounds manufactured by a living 
being, whereas audio signals include voice signals and all 35 
other signals that may be perceived by a listener. 

The audio source (102) provides a plurality of analog sig- 
nals on lines (114). One or more audioactive elements (104, 
106, 108, 110) convert the plurality of analog signals on lines 
(114) to a plurality of digital signals on lines (116). The 40 
audioactive elements (104, 106, 108, 110) also packetize the 
plurality of digital signals on lines (116). Packetization 
allows a digital signal to be separated into groups of bits, often 
referred to as packets. Accordingly, packets may be inter- 
spersed with other packets and propagated on a network or 45 
data connection using a transport protocol. A transport pro- 
tocol, for example, may include TCP/IP. Propagation on a 
network, e.g., an Ethernet based network, may use an address 
and a sequence number. Hie address determines a final des- 
tination for the packets and information about forwarding the 50 
packets from one computer or router to another computer or 
another router. The sequence number determines the proper 
order for the packets in case the packets are received out of 
order. Accordingly, a plurality of packets carrying digital 
signals from one of the audio sources is referred to as an audio 55 
stream. One of ordinary skill in the art will understand that 
multiple audio streams may be generated from a single audio 
source. Furthermore, multiple audio streams may be gener- 
ated from multiple audio sources. 

Hie audioactive elements (104, 106, 108, 110) may also 60 
encode the digital signals on lines (116). For example, the 
digital signals may be encoded in a MP3 (MPEG Audio Layer 
3) format, ITU G.723.1 voice coder format, or other format. 
Encoding may enable compression of the digital signals on 
lines (116). 65 

The packetized, and possibly, encoded digital signals on 
lines (116) use one or more hubs (120) to propagate the 
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packets to a voice over internet protocol (VOIP) encryption 
server (130). The propagation may use, for example, a uni- 
versal datagram protocol (UDP) service. The VOIP encryp- 
tion server (130) encrypts the packets such that unauthorized 
reception of encrypted packets does not allow the encrypted 
packets to be converted to a useful form. The encrypted pack- 
ets are propagated to a switch (140) using line(s) (133). One 
of ordinary skill in the art will understand that the encryption 
server (130) is representative of a device that encrypts the 
packets (i.e., an encrypter). 

The encrypted packets may propagate from the VOIP 
encryption server (130), for example, as multicast packets 
(packets transmitted using the multicast transport protocol). 
The encrypted packets may be sent to a unique multicast 
address/port combination. The unique multicast address/port 
combination provides the ability for audio players (182, 186, 

190. 196) operating on clients (180, 184, 188, 194) to receive 
and process each audio stream independently at a listener’s 
discretion, respectively. 

A campus intranet using multicast will see a total network 
load of the sum total of all of the audio streams regardless of 
the number of the listeners and the number of audio streams 
being monitored concurrently by the listeners. The VOIP 
encryption server (130) sends the encrypted packets as mul- 
ticast to the campus intranet. Routers (160, 164) in the cam- 
pus intranet distribute the encrypted packets as the multicast 
throughout the campus intranet with no further action being 
required of the VOIP encryption server (130). For example, 
encrypted packets may be uni-directionally propagated on 
lines (133, 143, 183, 163, 187, 191, 197). 

The audio players (182, 186, 190, 196) perform a variety of 
tasks that may include user authentication through a server 
such as an NT domain server (150), access verification using 
an access list (125), multicast join for each of the audio 
streams, decrypting the encrypted packets, directing the 
selected audio streams for audio playback, and modifying the 
audio playback. When an audio player (182, 186, 190, 196) 
starts, the listener is prompted for an ID and password. The 
audio player (182, 186, 190, 196) validates the listener 
against a specific NT domain server (150) database to assure 
authentication using lines (151, 161, 181, 185, 189, 195). 

Additionally, the audio player (182, 186, 190, 196) verifies 
that the listener has access authorization to the audio streams 
using an access list (125) and lines (127, 161, 181, 185, 189, 
195). User authentication may be afforded to a large number 
of listeners. Access list (125) authorization may be afforded 
to a reduced number of listeners, and may cause the audio 
player (182. 186, 190, 196) to indicate a presence of a limited 
number of the available audio streams. Once both of these 
checks are completed, a control window for the audio player 
(182, 186, 190, 196) is presented to the listener. One of 
ordinary skill in the art will understand that a plurality of lines 
connecting two or more elements may be physically routed on 
a plurality of lines or virtually routed on a single line. 

The audio player (182, 186, 190, 196) decrypts the 
encrypted packets received from the VOIP encryption server 
(130). The decrypting results in reproducing a copy of packets 
from an audio stream. The audio player (182, 186, 190, 196) 
directs the selected audio streams for audio playback. In one 
or more embodiments, the audio player (182, 186, 190, 196) 
may send the audio packets to a multimedia subsystem of the 
client (180, 184, 188, 194) using an application program 
interface. In one ormore embodiments, the audio player (182, 

186. 190. 196) may send the audio packets to another device 
or software interface operatively connected to the client (180, 
184, 188, 194) for audio playback. 
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In one or more embodiments, the audio player (182, 186, 
190, 196) may allow modification of the audio playback of an 
audio stream. Modifying may include changing a volume, 
muting, and stopping an audio playback. In one or more 
embodiments, the audio player (182, 186, 190, 196) may also 
allow modification by stopping the propagation of an audio 
stream to the client (180, 184, 188, 194), starting the propa- 
gation of an audio stream to the client (180, 184, 188, 194), 
and flushing a stream buffer of an audio streams. 

One of ordinary skill in the art will understand that addi- 
tional lines between elements of the campus intranet may 
exist. The additional lines may enable communication not 
specifically described. For example, communication between 
the switch (140) and the router (160) may use line (141). 

In FIG. 2, the communication system (100) resides on a 
campus intranet. FIG. 3 shows a block diagram of an exem- 
plary communication system (200) in accordance with an 
embodiment of the present invention. The communication 
system (200) allows encrypted packets to travel beyond a 
campus intranet to a remote site intranet using, for example, 
an Internet (299). 

A plurality of audio sources are available at an audio source 
(202). An audio source may include audio signals and/or 
voice signals. The audio source (202) provides a plurality of 
analog signals on lines (214). One or more audioactive ele- 
ments (204, 206, 208, 210) convert the plurality of analog 
signals on lines (214) to a plurality of digital signals on lines 
(216). The audioactive elements (204, 206, 208, 210) also 
packetize the plurality of digital signals on lines (216). 

The audioactive elements (204, 206, 208, 210) may also 
encode the digital signals on lines (216). For example, the 
digital signals may be encoded in a MP3 (MPEG Audio Layer 
3) format, ITU G.723.1 voice coder format, or other format. 
Encoding may enable compression of the digital signals on 
lines (216). 

The packetized and possibly encoded digital signals on 
lines (216) use one or more hubs (220) to propagate the 
packets to a voice over internet protocol (VOIP) encryption 
server (230). The propagation may use, for example, a uni- 
versal datagram protocol service. The VOIP encryption 
server (230) encrypts the packets such that unauthorized 
reception of encrypted packets does not allow the encrypted 
packets to be converted to a useful form. The encrypted pack- 
ets are propagated to a switch (240) using line(s) (233). 

The encrypted packets may propagate from the VOIP 
encryption server (230), for example, as multicast packets. 
The encrypted packets may be sent to a unique multicast 
address/port combination. The unique multicast address/port 
combination provides the ability for audio players (282. 286, 
290) operating on clients (280, 284, 288) to receive and pro- 
cess each audio stream independently at a listener’s discre- 
tion, respectively. The VOIP encryption server (230) sends 
the encrypted packets as multicast to the campus intranet. 
Router (260) in the campus intranet distributes the encrypted 
packets as the multicast throughout the campus intranet with 
no further action being required of the VOIP encryption 
server (230). For example, encrypted packets may be uni- 
directionally propagated on lines (233, 243, 273). 

A single campus intranet may be extended to a remote site 
intranet using, for example, an Internet (299). Encrypted 
packets may be propagated from the VOIP encryption server 
(230) to a VOIP UDP distribution server (296) using one or 
more switches and routers such as switch (240) and router 
(260). Encrypted packets may be uni-directionally propa- 
gated on lines (233, 243, 245). The VOIP UDP distribution 
server (296) allows the encrypted packets, even if using a 
multicast protocol, to be propagated through the Internet 
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(299) to the remote site intranet as UDP packets using lines 
(247, 287, 295). Additional routers, e.g., router (264), may 
propagate the UDP packets. A VOIP UDP distribution server 
(298) at the remote site intranet may recover the encrypted 
5 packets from the UDP packets and uni-directionally propa- 
gate the encrypted packets on lines (283, 285, 293). By using 
the multicast protocol, each of the campus intranet and the 
remote site intranet will see a total network load of the sum 
total of all of the audio streams, regardless of the number of 
to the listeners and the number of audio streams being moni- 
tored concurrently by the listeners. 

The audio player (282) performs a variety of tasks that may 
include user authentication through a server such as an NT 
domain server (250), access verification using an access list 
15 (225), multicast join for each of the audio streams, decrypting 
the encrypted packets, directing the selected audio streams 
for audio playback, and modifying the audio playback. When 
the audio player (282) starts, the listener is prompted for an ID 
and password. The audio player (282) validates the listener 
20 against a specific NT domain server (250) database to assure 
authentication using lines (251, 271). 

Additionally, the audio player (282) verifies that the lis- 
tener has access authorization to the audio streams using an 
access list (225) and lines (227, 271). User authentication 
25 may be afforded to a large number of listeners. Access list 
(225) authorization may be afforded to a reduced number of 
listeners, and may cause the audio player (282) to indicate a 
presence of a limited number of the available audio streams. 
Once both of these checks are completed, a control window 
30 for the audio player (282) is presented to the listener. 

Audio players (286, 290) perform a variety of tasks that 
may include user authentication through a server such as an 
NT domain server (292), access verification using an access 
list (228), multicast join for each of the audio streams, 
35 decrypting the encrypted packets, directing the selected audio 
streams for audio playback, and modifying the audio play- 
back. When the audio players (286, 290) start, the listener is 
prompted for an ID and password. The audio player (286, 
290) validates the listener against a specific NT domain server 
40 (292) database to assure authentication using lines (281, 291, 
295). 

Additionally, the audio players verify that the listener has 
access authorization to the audio streams using an access list 
(228) and lines (229, 281, 291). User authentication may be 
45 afforded to a large number of listeners. Access list (228) 
authorization may be afforded to a reduced number of listen- 
ers, and may cause the audio players (286, 290) to indicate a 
presence of a limited number of the available audio streams. 
Once both of these checks are completed, a control window 
50 for the audio players (286, 290) is presented to the listener. 

One of ordinary skill in the art will understand that a 
plurality of lines connecting two or more elements may be 
physically routed on a plurality of lines or virtually routed on 
a single line. 

55 The audio player (282, 286, 290) decrypts the encrypted 
packets received from the VOIP encryption server (230). The 
decrypting results in reproducing a copy of packets from an 
audio stream. The audio player (282, 286, 290) directs the 
selected audio streams for audio playback. The audio player 
60 (282. 286, 290) may send the audio packets to a multimedia 
subsystem of the client (280, 284, 288) using an application 
program interface. The audio player (282, 286, 290) may send 
the audio packets to another device or software interface 
operatively connected to the client (280, 284, 288) for audio 
65 playback. 

One of ordinary skill in the art will understand that addi- 
tional lines between elements of the campus intranet may 
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exist. The additional lines may enable communication not 
specifically described. For example, communication between 
the switch (240) and the router (260) may use line (241). 

FIG. 4 shows an exemplary flow diagram (300) of software 
instructions executable on an encrypter in accordance with an 5 
embodiment of the present invention. The flow diagram (300) 
describes a process in which the encrypter encrypts an audio 
stream. In FIG. 2 for example, the VOIP encryption server 
(130) encrypts the packets from the audio streams propagated 
from the audioactive elements (104, 106, 108, 110). to 

When an encrypter starts, a socket connection is estab- 
lished to one or more encoders that provides an audio stream 
(step 302). The socket connection may occur using a local 
area network (LAN). The encrypter also establishes a multi- 
cast connection to propagate data to one or more clients (step 15 
304). The multicast socket connection may occur using a 
wide area network (WAN). 

Once the socket connects are established (steps 302 and 
304), a packet from the encoders is read (step 306). The 
packet is assumed to be encoded in a MP3 format. The packet 20 
is encrypted (step 308). The encryption is assumed to be 
symmetrical RC4. One of ordinary skill in the art will under- 
stand that alternative encoding fonnats and encrypting algo- 
rithms may be used. The encrypted packet has a sequence 
number appended to protect against duplicate packet recep- 25 
tion (step 310). The encrypted packet with an appended 
sequence number is propagated on the WAN (step 312) and 
another packet from the encoders is read (step 306). Steps 306 
through 312 are then appropriately repeated. 

FIG. 5 shows an exemplary flow diagram (400) of software 30 
instructions executable on a client in accordance with an 
embodiment of the present invention. The flow diagram (400 ) 
shows a process in which a client establishes access to an 
encrypted audio stream and decrypts the encrypted packets 
for audio playback. When software instructions start for an 35 
audio player, for example audio players (182, 186, 190, 194) 
in FIG. 2, the software instructions request a listener to enter 
an ID and password (step 402). The ID and password are 
propagated to an authentication database (step 404). A com- 
parison of the ID and password entered in step 402 are com- 40 
pared to entries in the authentication database (step 406). If 
the comparison is successful, step 410 is followed. If the 
comparison is unsuccessful, step 408 is followed. In step 408, 
an error message is generated and steps 402, 404, and 406 are 
repeated. 45 

Once authentication has been achieved (step 406), access is 
determined (step 410). If a listener is on the access list, access 
to the audio streams is granted (step 412). Otherwise, access 
is not granted and the listener is sent back to step 402 via step 
414. 50 

In FIG. 5, an encrypted packet from the selected audio 
streams are decrypted and decoded (step 418). The decryp- 
tion is assumed to be symmetrical RC4. The packet is 
assumed to be encoded in a MP3 fonnat. One or ordinary skill 
in the art will understand that alternative encoding formats 55 
and encrypting algorithms may be used that will result in 
alternative decoding and decrypting algorithms. The 
decrypted, decoded packet is directed for audio playback. 
Step 418 is repeated until the listener quits the software 
instructions (step 420). 60 

FIG. 6 shows an exemplary client controls window (500) in 
accordance with an embodiment of the present invention. 
Referring to FIG. 6, the client controls window (500) exists as 
a Graphical User Interface (GUI), for example, a floating 
window with buttons to select audio streams, buttons to 65 
modify the audio playback, and indicators to provide infor- 
mation about the selected audio streams and modifications to 
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the audio playback. A GUI is part of a software application 
that interacts with a listener via a graphical display. The GUI 
receives input from the listener through different modes of 
access, such as a mouse and pointer combination, or through 
a keyboard. A visual output of a GUI is typically displayed on 
a display device, such as a computer monitor screen, and 
includes widgets that allow the user to interact with the GUI. 
Examples of widgets include windows, captions, buttons, 
labels, menu bars, toolbars, dialog boxes, menus, icons, etc. 
Widgets may also represent software applications float may be 
executed by the listener or a pointer icon that represents the 
position of the mouse. 

An exemplary GUI visual output of a client controls win- 
dow (500) is shown in FIG. 6. As shown, a client controls 
window (500) displays a text list indicating a presence of 
accessible audio streams in the left column. For example, 
International Space Station Flight Data 1 (ISS FD 1) (502) is 
one of nine accessible audio streams listed. Eight of the 
available nine audio streams are shown. Enlarging the client 
controls window allows the last audio stream to be displayed. 
Four of the nine audio streams are selected using the play 
buttons (504). The four selected audio streams are actively 
propagated on a data connection between a server and a client 
using a transport protocol. The remaining five audio streams 
are stopped, as indicated by the depressed stop buttons (506). 
The remaining five audio streams are not actively propagated 
to the client, however, all nine audio streams are actively 
propagated on a network by the server. Audio streams that are 
stopped may be started using play buttons (504). Audio 
streams that are playing may be stopped using stop buttons 
(506). Stopping a playback of an audio stream also stops that 
active propagation of the audio stream to the client. 

In FIG. 6, the four selected audio streams are directed for 
audio playback. The audio playback of the four selected audio 
streams may be modified. The audio playback of an audio 
stream may be muted using buttons (510). The volume of the 
four selected audio streams may be changed using slider 
buttons (512). The audio stream buffer may be flushed using 
buttons (508). In FIG. 6, indicators may provide information 
about the selected audio streams and modifications to the 
audio playback of the selected audio streams. Check boxes 
(514) indicate that a selected audio stream has active packets 
being received by the client. A numerical indicator (516) 
indicates a number of packets currently in the audio stream 
buffer. A VU meter (518) provides an indicator of a playback 
audio volume magnitude. 

To begin listening to audio streams, a listener selects a play 
button (504) of one or more audio streams to monitor. The 
client controls window (500) spawns a read process for the 
selected audio streams and the spawned process perfonns a 
multicast join request for the selected audio streams. A router, 
for example router 1 64 in FIG. 2 and router 2 64 in FIG. 3) will 
process the multicast join request and will begin sending the 
encrypted multicast packets to the spawned process created 
by the client controls window (500). The spawned process 
created by the client controls window (500) will receive, 
decrypt, decode, and direct for playback the encrypted mul- 
ticast packets. As a volume or muting feature is changed by a 
listener, interrupts are send to the spawned process to change 
those attributes of the audio stream directed for playback. 

FIG. 7 shows a glossary (600) for icons for an exemplary 
client controls window in accordance with an embodiment of 
the present invention. A text (602) listing indicates a presence 
of accessible audio streams. A play button (604) starts an 
active propagation of an encrypted audio stream to a client, 
the client decrypts and decodes the audio stream, and directs 
the audio stream for audio playback. 
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The stop button (606) stops an active propagation of an 
encrypted audio stream to the client, and stops the audio 
playback of the audio stream. A button (608) flushes an audio 
stream buffer. A button (610) toggles between muting and 
umnuting an audio playback. A muted audio playback moves 5 
a volume of the audio playback to zero; however, the audio 
stream is still actively propagated, decrypted, decoded, and 
directed for audio playback. 

In FIG. 7, a slider button (612) adjusts the volume of an 
audio playback. A numerical indicator (614) indicates a num- to 
ber of packets currently in an audio stream buffer. A VU meter 
(616) provides an indicator of a playback audio volume mag- 
nitude. An indicator (618) indicates that a client controls 
window has lost a connection to an audio stream(s). A button 
(620) causes a client controls window to display only the 15 
audio streams that are running. A button (622) causes a client 
controls window to display all of the audio streams that are 
accessible to a listener dependent on privilege. A button (624) 
flushes all audio stream buffers. A button (626) mutes an 
audio playback of all audio streams. A button (628) disables 20 
the mutes of an audio playback of all audio streams. A text 
indicator (630) displays the number of selected audio streams 
and the number of accessible audio streams. 

Advantages of the present invention may include one or 
more of the following. In one or more embodiments, because 25 
a packetized version of an audio source is propagated on a 
data connection between a server and a client, a dedicated 
connection does not have to be created between the audio 
source and a listener. 

In one or more embodiments, because a communication 30 
system includes audio streams, a data connection between a 
server and a client, an encrypter for encryption of the audio 
streams, and an audio player on the client that allows ad hoc 
selection of the audio streams, the communication system has 
a lower cost than a dedicated network and authentication and 35 
access maybe controlled. Furthermore, situational awareness 
may be extended to a larger number of listeners, often in the 
listener’ s usual business setting. A special listening area is not 
required. 

In one or more embodiments, a transport protocol includes 40 
a multicast protocol. A network load caused by propagating a 
plurality of audio streams will be a load of the plurality of the 
audio streams being propagated, regardless of the number of 
the listeners and the number of audio streams being moni- 
tored concurrently by the listeners. In other words, a network 45 
loading is dependent on the number of concurrent audio 
streams being actively propagated and not the number of 
listeners or the number of audio streams each listener has 
selected or hears. 

In one or more embodiments, a transport protocol includes 50 
a UDP protocol such that encrypted audio streams from a 
campus intranet may be extended to a remote site intranet. 

In one or more embodiments, because a plurality of audio 
streams is propagated to a client, multiple audio streams may 
be monitored simultaneously. Furthennore, ad hoc selection 55 
of actively propagated audio streams provides a listener the 
ability to monitor near real-time multiple concurrent audio 
streams. 

In one or more embodiments, an audio player allows a 
listener a capability to individually control audio volume and 60 
muting for each audio streams on a real-time basis. Additional 
modifications to each audio stream and indicators for each 
audio stream may advantageously be provided by the audio 
player to the listener. 

In one or more embodiments, a co mm unication system is 65 
described that may provide monitor capability to supervisors 
of air traffic controller communication with Airline Pilots and 
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traffic controller training, stock exchange broker conference 
monitoring, and/or police, fire, or EMS dispatch monitoring. 
In addition, it would be possible to set up a web site for the 
general public to listen to select loops from their home com- 
puters. 

While the invention has been described with respect to a 
limited number of embodiments, those skilled in the art, 
having benefit of this disclosure, will appreciate that other 
embodiments can be devised which do not depart from the 
scope of the invention as disclosed herein. Accordingly, the 
scope of the invention should be limited only by the attached 
claims. 

What is claimed is: 

1 . A process of operating a data processor of known type to 
enable the processor to execute instructions in an object pro- 
gram comprising a plurality of instructions, the instructions 
comprising: 

instructions for indicating a presence of at least two audio 
streams corresponding to at least two distinct audio 
sources actively and simultaneously propagated from a 
server; 

instructions for ad hoc selecting of at least two of the at 
least two audio streams dependent on a listener, wherein 
at least two of the at least two distinct audio sources are 
represented in the selected at least two of the at least two 
audio streams; 

instructions for directing the selected at least two of the at 
least two audio streams for simultaneous audio play- 
back; and 

instructions for decoding the selected at least two of the at 
least two audio streams directed for simultaneous audio 
playback. 

2. The process of claim 1, further comprising instructions 
for decrypting the selected at least two of the at least two 
audio streams directed for simultaneous audio playback. 

3. The process of claim 1, further comprising instructions 
for modifying the simultaneous audio playback, 

4. The process of claim 3, wherein modifying includes at 
least one selected from the group consisting of changing a 
volume of at least one of the selected at least two of the at least 
two audio streams, muting at least one of the selected at least 
two of the at least two audio streams, flushing an audio stream 
buffer of at least one of the selected at least two of the at least 
two audio streams, and stopping the simultaneous audio play- 
back of at least one of the selected at least two of the at least 
two audio streams. 

5. A computer system for communications, comprising: 

a processor; 

a memory; and 

software instructions stored in the memory adapted to 
cause the computer system to: 

indicate a presence of at least two audio streams corre- 
sponding to at least two distinct audio sources actively 
and simultaneously propagated to a client; 
select at least two or the at least two audio streams 
dependent on a listener, wherein at least two of the at 
least two distinct audio sources are represented in the 
selected at least two of the at least two audio streams; 
direct the selected at least two of the at least two audio 
streams for simultaneous audio playback; and 
decode the selected at least two of the at least two audio 
streams directed for simultaneous audio playback. 

6. The computer system of claim 5, further comprising 
software instructions to decrypt the selected, at least two of 
the at least two audio streams directed for simultaneous audio 
playback. 
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7. The computer system of claim 5, further comprising 
software instructions to modify the simultaneous audio play- 
back. 

8. The computer system of claim 7, wherein the software 
instructions to modify the simultaneous audio playback per- 5 
form at least one selected from the group consisting of change 
a volume of at least one of the selected at least two of the at 
least two audio streams, mute at least one of the selected at 
least two of the at least two audio streams, flush an audio 
stream buffer of at least one of the selected at least two of the 
at least two audio streams, and stop the simultaneous audio 
playback of at least one of the selected at least two of the at 
least two audio streams, 

9. A method for performing ad hoc selection of at least two 
audio streams, comprising: 

packetizing the at least two audio streams; 
actively and simultaneously propagating the at least two 
audio streams from a server to a client; 
indicating a presence of the at least two audio streams is 
performed by the client; 

selecting at least two of the at least two audio streams is 
performed by the client dependent on a listener; 
directing the selected at least two of the at least two audio 
streams for simultaneous audio playback; 
encoding the selected at least two of the at least two audio 
streams; and 

decoding the selected at least two of the at least two audio 
streams is performed by the client, 
wherein the at least two audio streams correspond to at 
least two distinct audio sources, and 
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wherein at least two of the at least two distinct audio 
sources are represented in the selected at least two of the 
at least two audio streams. 

10. The method of claim 9, further comprising encrypting 
the selected at least two of the at least two audio streams. 

11. The method of claim 10, wherein the encrypting is 
performed by the server. 

12. The method of claim 10, further comprising decrypting 
the selected at least two of the at least two audio streams is 

10 performed by the client. 

13. The method of claim 9, wherein the at least two audio 
streams are actively and simultaneously propagated using a 
multicast protocol. 

15 14. The method of claim 9, further comprising modifying 

the simultaneous audio playback. 

15. The method of claim 14, wherein the modifying 
includes at least one selected from the group consisting of 
changing a volume of at least one of the selected at least two 

20 of the at least two audio streams, muting at least one of the 
selected at least two of the at least two audio streams, flushing 
an audio stream buffer of at least one of the selected at least 
two of the at least two audio streams, and stopping the simul- 
taneous audio playback of at least one of the selected at least 

25 two of the at least two audio streams. 

16. The method of claim 9, wherein at least one of the 
selected at least two of the at least two audio streams contains 
voice communication. 



